Top-level statements can co-exist with type declarations, but must come first. Is there a similar rule for top-level members?

Would such types be in the namespace or nested in the TopLevel type? From the spec it should be in the namespace (since types are not allowed as top-level members), but that's surprising. So it may be better to just disallow them...

That's a good question, I will add it to the list. But I don't find the behavior surprising, consider that you have an existing code like

namespace N;
class C;

and you decide to add a top-level member, for example

namespace N;
int M() => 42;
class C;

that could be disallowed but if it's allowed it seems natural that the class remains directly in the namespace as it was before.

if it's allowed it seems natural that the class remains directly in the namespace as it was before.

That's arguable, but not obvious. What if I sandwich the type?

namespace N;
int M() => 42;
class C;
int M2() => 42;

It doesn't seem obvious why M() and M2() are in N.TopLevel, but C is directly in N

My $0.02: There's been many a request to "reduce the indentation" with file-scoped classes (like file-scoped namespaces), and the team has rejected them for a variety of reasons — I would too. Combining top-level members with file-scoped types sounds like a recipe for disaster.

@jcouv

It doesn't seem obvious why M() and M2() are in N.TopLevel, but C is directly in N

Aren't you taking on a little too much implementation detail here? As far as the user is concerned M and M2 are just functions in the namespace N. The fact that a containing class is generated for them would be--and should be--entirely hidden from the user.

You could even nominally think of each top-level member as being given its own, generated, containing class. As long as the members can still see each other it makes no difference from a usability standpoint.

To put it another way, my mental model of how this should work goes like this:

Rather than thinking "If this file contains top-level members then lift the contents of the file into a generated class" I think "For each declaration in this file, if the declaration is a type then leave it as-is, if it's a member then lift it into a generated class".

So

namespace N;

void M1() {}

class C1 {}

void M2() {}

class C2 {}

void M3() {}

becomes

namespace N;

partial static class TopLevel
{
    void M1() {}
}

class C1 {}

partial static class TopLevel
{
    void M2() {}
}

class C2 {}

partial static class TopLevel
{
    void M3() {}
}

I definitely don't like this or expect this. I would expect members without modifiers to have the narrowest accessibility (so only visible within the file.

To be visible outside, you'd need to be explicit about internal/public.

I think it is expected because it's the default visibility for everything that language currently allows to be top-level (classes/structs/delegates/enums).

For example, I think this is pretty unsatisfactory:

// util.cs
namespace MyApp;

// Implicitly `internal`
class MyThing(string _) {}

// Implicitly `private` or `file`
MyThing CreateThing(string s) => new MyThing(s);

Come to think of it, this raises another question: what happens to types declared inside a file that also contains top-level members? Using the example above, we could take it to mean either (a):

// util.cs
namespace MyApp;

static class <>__Generated
{
  class MyThing(string _) {}
  
  // Implicitly `private` or `file`
  MyThing CreateThing(string s) => new MyThing(s);
}

or (b)

// util.cs
namespace MyApp;

// Implicitly `internal`
class MyThing(string _) {}

static class <>__Generated
{
  // Implicitly `private` or `file`
  MyThing CreateThing(string s) => new MyThing(s);
}

Of the two I think (b) makes more sense†, in which case my initial reaction to visibility stands.

† I think (b) is preferrable to (a) because, otherwise, adding a top-level member to a file would suddenly nest all the classes declared in that file, potentially hiding them.

I think (b) is preferrable to (a) because, otherwise, adding a top-level member to a file would suddenly nest all the classes declared in that file, potentially hiding them.

Agreed, I said that as well in another discussion above (#9719 (comment)).

Although it might just be disallowed to mix existing declarations with the new top-level ones to avoid these kinds of issues.